CRA사용을 멈춰라

Stop Using Create React App

• 최근 굉장히 CRA의 문제점에 대해서 재미있는 토론과 주장들을 보았는데 내용이 너무 재미있고 새롭게 공부한 내용들이 많아서 정리해보려고 한다.

시작

• facebook/create-react-app repository에 issue가 한 개 올라오게 되었는데 해당 이슈는 백엔드 패키지를 프론트엔드 앱에서 설치하는데 발생한 문제에 관한 이슈였다. 여기서 이루어진 대화들은 백엔드 패키지들을 모두 polyfill하지 못해서 발생한 문제였고 추가적으로 이와 비슷한 현상을 겪거나 파생한 문제들을 다른 사람들도 댓글을 달면서 화두가 되기 시작했고 결과적으로는 지금 CRA는 이런 문제에 대한 해결책이 없고 좋은 방향을 제시해줄수 없는것 같다는 느낌이였다.

polyfill이 그래서 뭔가?

• polyfill은 여러가지 이유로 현재 사용중인 장치에서 실행할 수 없는 코드를 작성한걸 의미하고 이걸 해결하기 위한 방법인데 예를 들면 array.map과 같이 우린 js파일에서 사용하지만 array.map이 없는 일부 브라우저에 대해 뭐 예로 Internet Explorer를 대상으로 하는 경우 컴파일 타임에 for loop에 대한 구식을 생성한다. 도트 맵이 작동하도록 하기 위해서 polyfill은 지원되지 않는것을 최신의 것으로 호환가능하게 만들기 위해 이전 스타일 또는 지원되지 않는 스타일을 사용하는 코드이다.
• 이제 문제가 되었던게 이와 관련된 트위터 게시글에서 node할 수 있는 모든것을 polyfill 하면되지 않냐는 글이 있어서 엄청나게 욕을 먹었다.
  • 지금도 현재 표준화를 위한 여러 그룹과 팀들이(ex. w3g etc) 자바스크립트 명령 및 기능의 기본 세트가 브라우저든 노드든 클라우드 플레이 작업자든 표준화를 하기 위해서 여러 해결책을 놓고 논쟁하며 아직도 만들어가고 있는중이다.
  • 그래서 시작부분에 작성했던 issue가 crypto관련 문제였는데 node.js에서 사용하기 위한 모듈을 web에서 사용하려고 해서 이걸위해 수많은 쓸데없는것과 많은양의 모듈을 모두 폴리필하는게 정말 맞나? 라는 생각에서 시작되었던것 같다.

CRA가 왜 나쁜거지?

• CRA는 기본적으로 react사용을 위해서 상용구,튜토리얼,기술 구현과 빌드 시스템의 조합등등이 모두 초기 개발을 위해서 번들로 제공된다. ( 예전에는 웹팩을 직접 다 설정해야 했다는 무서운 글도 봤다. SPA를 위한 초기 solution으로 react가 나왔을 당시 같다. )
• 장점
  • 공식지원이 된다.
  • 커뮤니티가 굉장히 크다.
• 나쁜점
  • No SSR
  • 웹팩 아키텍처에 관한 잘못된 결정 (이 부분은 직접 다루어 보지 않아서 잘 모르겠다.)
  • 패키지에 필요하지 않은 것들로 매우 가득차있다.
  • 초기 node_modules의 용량이 300mb가 넘는다
  • 이상한 polyfill 동작이 생각하지 못한 상황을 우리에게 안겨줄때가 있다.
  • 오래된 React 패턴들을 기반으로 가지고있다. (ex. react-router)
  • 매우 많은 이상한 버그들이 존재한다. (1k가 넘음)
• 여러 주장들과 글들을 보면서 느낀점은 확실히 겪어본 상황들이 많았다. 일단 쓸데없이 용량이 매우큰것도 맞고 polyfill 동작의 문제로 패키지를 사용하지 못하거나 이상한 오류를 받는 경우도 많았고 react-router 특히 쓸데없이 거대하고 이상한 패키지들을 주루룩 달고 있는점 등등 모두 비슷한 문제들을 겪었다는점이 재미있었다.

그럼 대안으로 뭐가 있는가 ?

Next.js

• 장점
  • 엄청 현대적이다. 모던함이 있다.
  • metadata
  • SSR
  • 매우 정상적인 기준이 잡혀있다.
  • BackEnd solution을 제공함 (api, trpc etc)
  • 다중 렌더링을 위한 전략이 있다. (multiple render strategy)
  • 매우 훌륭한 caching story와 매우 빠른 빌드
• 단점
  • 아직 ESM에 관한 여러 이야기들이 정리가 안되어있다.
  • 프론트엔드와 백엔드의 불분명한 경계를 가지고있다.
  • "GetServerSideProps"는 안티패턴을 가지고있다.

Vite

• 장점: Simple....
• 단점: No SSR....

상황에 맞게 뭐를 사용하는게 좋을까?

• 우선 글에서 보았던 여러 해외의 네임드 개발자들과 아닌 개발자들 또한 Vite와 Next.js를 많이 사용하는것으로 보였다. 최근 Vite을 많이 사용했는데 잘못되지는 않았구나 싶었다. ㅋㅋ

• Create React App

  • 이미 코드베이스가 CRA로 되어있는경우. (장난으로 돈을 덜 받고싶으면 CRA사용하라는 농담도 있었다 :D)

• Vite

  • SSR을 나중에라도 고려하지 않아도 되는경우
  • build를 직접 소유하고 있는것이 가치가 있는경우(이건 사실 나의 영어수준 이슈로 제대로 해석이 안되었다... 아니면 내가 이해를 못했을수도 있다.)
  • Raw Speed를 사용하고싶은 경우 (esbuild가 golang으로 만들어서 꽤 빠른것같다.)

• Next.js

  • 만약 html, metadata ,SEO, lighthouse, 첫 번째 paint의 성능이 중요한 경우
  • 앞서 얘기했던 CRA의 문제에 대해서 더 생각하고싶지 않은 경우
  • 새로운 표준을 사용하고 싶은 경우

CRA를 멈추는걸 정말 고려해야 할 시점은?

• SSR이 우리 서비스 및 내가 만드는 서비스에 있어서 얼마나 중요한가?

  • metadata가 필요한가? (google, embeds etc)
  • static html이 필요한가?

• 구인구직에 있어서 당신이 중요한 시점에 있는 상태인가 (해외는 정말 CRA를 많이 피하는건가 싶은 내용이였다. 면접볼때 CRA에 관해서 많이 물어보려나..?)

• 성능이 중요한가?

• 마지막으로 그냥 이 이유만으로도 쓰지말라고 정리해놓은 내용이 있었는데 그 내용은 아래와 같다.

• CRA시 받는 react-router에 다양한 경로가 있고 이상한 polyfill과 plugins들이 굉장히 많다. 그냥 cra 하는 순간 우리의 codebase에 10000줄이 넘는 코드를 그냥 깔고 시작하는거고 우린 그게 어디있는지 찾을수도 없다. 그리고 대다수의 개발자들은 이 10000줄이 넘는 코드가 매우 필요없는 경우가 많을것이다. 그런데도 쓸것인가? CRA보다 더 좋은 방법과 해결법은 이미 나와있다. 선택의 당신이 직접해라. 라는 내용이였다.

• 굉장히 많은 해외 개발자들이 CRA를 안좋아한다는걸 처음 알기도했고 급진적인 분들도 많아보여서 더 재미있게 논쟁들을 구경했던것 같다. 오랜만에 재미있게 글도 많이 읽고 새롭게 알게된것들도 많아서 좋은 시간이였다 :D